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Abstract 

KBSDE is a knowledge compiler that uses a 
classification-based approach to map solution con- 
straints in a task specification onto particular 
search algorithm components that will be respon- 
sible for satisfying those constraints local 

constraints are incorporated in genera t:*: global 
constraints are incorporated in either »sters or 
hillclimbing patchers). Associated with each type 
of search algorithm component is a subcompiler 
that specializes in mapping constraints into com- 
ponents of that type. Each of these subcompil- 
ers in turn uses a classification- based approach, 
matching a constraint passed to it against one of 
several schemas, and applying a compilation tech- 
nique associated with that schema. 

While much progress has occurred in our research 
since we first laid out our classification-based ap- 
proach [Ton91], we focus in this paper on our re- 
formulation research. Two important reformula- 
tion issues that arise out of the choice of a schema- 
based approach are: 

% Compilability . Can a constraint that does not 
directly match any of a particular subcompiler’s 
schemas be reformulated into one that does? 

• Efficiency. If the efficiency of the compiled 
search algorithm depends on the compiler’s per- 
formance, and the compiler’s performance de- 
pends on the form in which the constraint was 
expressed, can we find forms for constraints 
which compile better, or reformulate constraints 
whose forms can be recognized as ones that 
compile poorly? 

In this paper, we describe a set of techniques we 
are developing for partially addressing these is- 
sues. 

Introduction 

Because we have described KBSDE more extensively 
elsewhere [Ton91], our introduction to the basic ideas 
behind KBSDE will be relatively brief. 


Rooms lengths must be at least ainValusl. 
Rooms widths must be at least ninValu*2 . 
Rooms must be inside the floorplan. 

Rooms must be adjacent to the floorplan 
boundary. 

Rooms must not overlap. 

The rooms must completely fill the floorplan 
i space. 


(MINL) 

(MINW) 

(INS) 

(ADJ) 

(NONOV) 

(FILL) 


Figure 1: Constraints on house floorplans 


Task specifications. KBSDE accepts task spec- 
ifications that can be expressed in the form: 

Synthesize^ : J, o : 0) | P{o) 


where i is the input defining a particular problem, 
o is a candidate solution, O (the type of the object o 
to be synthesized) defines the space of candidate solu- 
tions, and P(o) is a predicate on o that must be sat- 
isfied. P(o) is expressed as a conjunction of simpler 
constraints. 

Many design tasks can be specified in this m - ner. 
- r example, the specification for a simple hous o 0 r- 
inning task might look like: 


Synthesize(< l : house Length, w : houseWidth , 
n : NbrRooms >, fp : Floorplan) 

| Acceptable Floor plan(fp) 

where Acceptable Floorplan(fp) is the conjunction 
of the constraints listed in Figure 1. 

Algorithm descriptions. KBSDE’s top-level clas- 
sification partitions the conjoined constraints in P(o) 
into (mutually exclusive) subsets Pi(o) of constraints, 
where each subset is to be satisfied by a distinct al- 
gorithm component (either a constrained generator, a 
tester, or a hillclimbing patcher). Prototype heuristics 
for assigning constraints to algorithm components are 
discussed in [Ton91]. 

One example of a partitioning of the constraints in 
Figure 1 among a set of algorithm components is: 
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Synthesize(< / : H Length, w : HWidth , 
n : N br Rooms >, /p : Floorplan) 

Generate^ | Af JWI(/p) A MJtfW(/p) 
AJJVS(/p) A ADJ(/p)); 
if Test (/p | WCWOV(/p) A F/XX(/p)) fails 
then Patch (fp | NONOV(fp) A FILL(fp )); 
Return(/p). 


The intended semantics of this syntax is: generate an 
s; if the tested constraints fail, then try to patch; if 
patching fails, chronologically backtrack to the gener- 
ator. Later references to Tests in this paper are in- 
tended to have the same semantics with respect to test 
failure and backtracking to preceding generators. 

Algorithms themselves can be partitioned across sev- 
eral levels of abstraction. For example, 


Synthesize(< / : H Length, w : HWidth , 

n : N br Rooms >,fp : Floorplan) 
Generate(< ai : area(Room), 

a n : area(JZoom) >); 

Test(< a\, ..., a n >| / * w = ai + a* + ... + a„); 
high level 


low level 

For i = 1 to n do 
Generate^,* : Room | MINLfa) 
AMINW(ri) A INS(ri) 

A ADJ(ri) A Area(pi) = a,*); 
rooms(fp) —< r u ...,r„ >; 
if Test(/p | NONOV(fp) A FILL(fp)) fails 
then Patch (fp | NONOV(fp) A FILL(fp)); 
Return(/p). 


Constraints are thus partitioned across levels as well as 
across the algorithm components within each level. In 
addition, inter-level constraints (such as Area(pi) = 
a>i) are dynamically posted to ensure that a solution 
generated at the next level down is a refinement of the 
solution at the current level. 

Reformulating constraints for 
incorporation into generators 

The RICK subcompiler (the subject of Wes Braud- 
away’s Ph.D. work [Bra91b, Bra91a]) of KBSDE spe- 
cializes in incorporating local solution constraints c 
into generators of all instances s of a given type T. 
The result is a constrained generator \ whose computed 
range of values is guaranteed to include only those in- 
stances of T that satisfy c; this is typically accom- 
plished by either changing the lower or upper bounds 
of the range, or pruning out inconsistent values and 
caching the remainder. Note that T can be non- 
numerical, and hierarchical in structure (e.g., a rect- 
angular floorplan is composed of rectangular rooms; 


each room is defined in terms of 4 parameters: < 

>). 

Compilability 

The structure mismatch problem. The generator 
structure of a an algorithm is its internal organization 
of generator components. Different generator struc- 
tures can be constructed for the same task. Some gen- 
erator structures do not allow the incorporation of all 
constraints. We refer to this as the structure mismatch 
problem . 

The structure mismatch problem is actually a family 
of problems, as illustrated in Figure 2, which indicates 
all the activities involved in RICK’s process of design- 
ing a constrained generator. Each such decision ((a) 
through (h)) can be “bollixed” by its own unique struc- 
ture mismatch problem. For example, decision (a) - 
partitioning requirements - takes a set of requirements 
R(s) and decides which will be treated as local, type- 
defining constraints T(s), which will be considered as 
semi-local constraints C(s) on interfacing parts of s, 
and which will be considered global constraints P(s); 
which constraints can be treated as type-defining de- 
pend on the known datatypes. 

The RICK subcompiler avoids the structure mis- 
match problems associated with decision (e) (the 
choice of low-level object structure), decision (g) (the 
choice of composition architecture), and decision (h) 
(the choice of control flow) by using a least commit- 
ment approach to top-down refinement of the genera- 
tors that is constrained by the constraints to be incor- 
porated [Bra91b]. 

Thus for theses decisions, RICK avoids the need for 
a reformulation-based approach to the structure mis- 
match problem. However, RICK does require reformu- 
lation for a particular special case of decision e) which 
we now describe. 

Reformulation to eliminate terminological mis- 
match between constraint and generator. If a 
constraint c refers to an object obj that is semanti- 
cally a dynamically generated part of solution o (e.g., 
the points inside rectangle R) but that does not appear 
syntactically as a part or parameter of o (according 
to the given type definition T), then c cannot be di- 
rectly incorporated into the generator of ail instances 
of type T (since the hierarchical structure of the gen- 
erator procedure is directly lifted from the syntactic 
structure of T). Incorporation is enabled by using re- 
formulation techniques that reexpress c solely in terms 
of the defined parts and parameters of T. 

For example, constraint INS, “Rooms must be inside 
the floorplan”, might originally be expressed as “If a 
point is inside a room, than that point is also inside 
the floorplan”: 

ViZ, Pl{Room(R) A Point(P) A z(stz;(iZ)) < s(P) 

< x(ne(JZ)) A y(su>(R)) < y(P) < t/(ne(iZ))] 
[x(sw(floorplan)) < x(P) < x(ne( floorplan )) A 
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Generateis I R(s)) 

Knowledge Level I . . 

Decisions • ( a ) Petitioning Requirements 

• (b) Object Election • (£) Artifact • (i) Concept Formulation 

Architecture 

• (c) Object ' ructnre • (j) Referenced Architecture 

• (k) Terminology 

1 l t 

Synthesis Knowledge T(s) Composition Knowledge C(s) Analysis Knowledge P(s) 


• (d) Generator Order 

• (g) Composition 

Architecture 

• (e) Low-level Structure 

f ’ 

• (h) Control Flow 


Generate 

Components 


Compose 

Components 


Function Level 
Decisions 



Test Artifact 
Candidate 


Figure 2: Design decisions defining a family of structure mismatch problems 


156 





y(sw(floorplan)) < y(P) < y(ne(floorplan))]] 

The problem is that T, the part decomposition for 
objects of type Floorplan, does not include points P 
in the interior of a room. The RICK system uses the 
transitivity of the “<” relation to hypothesize a plau- 
sible reformulation of the above constraint that does 
not refer to points P, and instead, simply constrains 
the extreme points of room R: 


ViE 


Room(R) — ► 

x(sw( floorplan)) < x(sw(R)) < x(ne( floorplan )) A 
y(sw( floorplan)) < y(sw(R)) < y(ne(//oorp/an))A 
x(sw(floorplan)) < x(ne(R)) < x(ne(/Joorplan))A 
y(sw( floorplan)) < y(ne(IE)) < y(ne( floorplan))]] 


RICK then uses a standard theorem- proving technique 
to verify that this hypothesized reformulation is a nec- 
essary condition for the original constraint. 


Reformulation by eliciting simplifying assump- 
tions. Because RICK uses the simplex method to 
check the consistency of a set of constraints (a neces- 
sary step along the way to constructing a constrained 
generator satisfying those constraints), all such con- 
straints must ultimately be expressible in a linear alge- 
braic form in order for compilation to proceed. Some- 
times, however, constraints that could be reformulated 
as linear constraints depend for their reformulation 
upon knowledge not available in RICK’s knowledge 
base. 

For example, in our house floorplanning example, 
floorplans and rooms are defined to be rectangular. 
Rectangles in general need not be aligned horizontally 
or vertically in the Cartesian plane; thus, the type def- 
inition for a general rectangle will have associated the 
nonlinear constraint: 

[x(nu;(R)) - x(sti/(R))] * [x(se(R)) — x(sis(R))] = 
[y(nw(R)) - y(sw(R))] * [y(se(R)) - y(sw(R))] 

However, were RICK to know that: 
x(nu;(R)) = x(su;(fE)) 

i.e., we can consider the rectangle to be vertically 
aligned with the y axis, then because (non-degenerate) 
rectangles also have the associated constraint: 
y(sw(R)) < y(nw(R)) 

the constraint could be reduced to the linear con- 
straint: 


y(se(R)) ~ y(sw(R)) 

i.e., “the rectangle is horizontally aligned with the x 
axis.” 

If at any point, compilation comes to a halt be- 
cause the only constraints left to compile are nonlin- 
ear, RICK consults the user, by presenting a list of 
plausible simplifying assumptions . These simplifying 
assumptions are generated by heuristics that examine 
a nonlinear constraint and consider what would have 
to be true in order for it to be reducible to a linear con- 
straint. Thus if (x - y) appears in a product, “x = y” 


would simplify the constraint if it were true; if xy ap- 
pears in a sum, x = 1/y would simplify the constraint. 

The generation (and select ion /verification by the 
user) of such simplifying assumptions is intended to 
mimic the form of mathematical reasoning, “Without 
loss of generality, let us assume The user is in- 
volved in this process because, in general, actual verifi- 
cation of such simplifying assumptions requires knowl- 
edge that is not available in the system’s knowledge 
base. 

Efficiency improvement 

RICK’s task is to construct, for a given constraint c(o), 
where o is of type T, a constrained generator of objects 
of type T that are guaranteed to satisfy c. Thus, no 
matter how it chooses to represent solutions or incor- 
porate the constraint, if RICK fully incorporates c into 
the generator, the set of solutions generated will always 
be the same. Since RICK does not reason about “low. 
level” issues such as choice of data structure for solu- 
tions, the primary issue regarding efficiency is whether 
the constructed constrained generator - which sequen- 
tially produces all the members of the set {o | c(o)} - 
is producing duplicate candidate solutions in that se- 
quence. 

One reformulation technique used by RICK to help 
reduce the construction of redundant solutions is based 
on knowing that if RICK is passed a constraint of the 
form: 

V*, y[P — ♦ X = y] 

it will “operationalize” this by constructing generators 
for objects x and y, generate one object first (say, x), 
and then construct y to be an exact copy of x. RICK 
avoids this undesirable behavior by looking for such 
constraints, forming their logical contrapositive (ex- 
cept for the type-defining terms), and then reexpress- 
ing the constraint in a canonical form. 

For example, the NO NOV constraint, “Rooms must 
not overlap”, might originally be expressed as: 

VR1, R2, P[room( HI) A room(R2) A point(P) 
AstrictlyInside(P i JE1)A 
strictly I ns ide(P, R2) — > JZ1 = R2] 

The contrapositive is: 

VR1, J22, P[room(R\) A room(JE2) A R1 A point(P) 
AR1^R2- 

~ strictlyInside(P \ JE1)V ~ strictly In$ide(P, /E2)] 
which is then put in canonical form: 

VR1, JE2, P[room(R\) A room(R2) A R1 A point(P) 

A strictlylnside(P) Rl) 

ARl £ R2 strictlyInsidc(P , JE2)] 

Reformulating constraints for more 
efficient function evaluation 

The MENDER subcompiler (the subject of Kerstin 
Voigt’s Ph.D. work [VT89]) of KBSDE specializes 
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in incorporating global constraints c into hillclimb- 
ing patchers; these patchers take a candidate solu- 
tion s that fails test c, and iteratively modifies s, one 
parameter value at a time, in such a way that im- 
provement occurs with respect to an evaluation func- 
tion f. f is constructed by MENDER so that there 
is some value k such that when hillclimbing reaches 
/( s) > J b, c(s) is simultaneously satisfied. For exam- 
ple, the FILL constraint, “The rooms must completely 
fill the floorplan space” is completely satisfied when 
f(s) = H Length ♦ HWidth , where f(s) is the number 
of lxl “unit tiles” in the floorplan that are covered by 
rooms. 

MENDER handles those global constraints that can 
be viewed as resource assignment problems (RAPs) 
involving assigning a fixed set of resource units to a 
dynamically generated set of consumers in a specified 
way. For example, the FILL constraint can be viewed 
as a RAP wherein the the resources are unit tiles in 
the rectangular floorplan, the consumers are rectangu- 
lar rooms and the required assignment is that each re- 
source unit be assigned (at least) one consumer. (Note 
that other constraints such as NONOV and INS en- 
sure that each resource unit is assigned exactly one 
consumer.) 

Compilation is based on a taxonomy of resource 
assignment problem schemas , where what is varying 
acroes the schemas is the nature of the assignment 
(one-to-one, onto, etc.) Associated with each schema 
is a method for constructing an evaluation function ap- 
propriate for that kind of RAP. Thus the schema for 
an “onto” assignment (such as FILL) has an associated 
evaluation function which counts the total number of 
resource units “covered” by consumers in a particular 
state. 

Efficiency improvement 

The RAP schemas can be organized into a specializa- 
tion lattice. More specialized schemas have more con- 
straints on the assignment; because, therefore, more is 
known about such RAPs, they also often have more ef- 
ficiently evaluatable functions. For example, the most 
specialized RAP, where the relation between resource 
units and consumers is “one-to-one” and “onto” (e.g., 
as between unit tiles in the floorplan and unit tiles in 
the room rectangles), can take advantage of the fact 
that all the consumers must have associated resource 
units assigned to them. (The nature of the overall 
search algorithm architecture in which the hillclimbing 
patcher is embedded guarantees that the patcher will 
be passed a candidate solution that satisfies the “one- 
to-one” constraint, though not necessarily the “onto” 
constraint.) It further relies on the common occurrence 
of a strictly hierarchical structure in the consumer or- 
ganization (e.g., the consumer unit tiles are grouped 
into rectangular rooms). On the basis of these facts, 
the associated evaluation function can count the to- 
tal number of “covered” resource units by counting 


the total number of assigned consumer units, which 
is the same as summing the sizes of the (mutually 
exclusive) consumer groups into which the consumer 
units are partitioned. Thus, if the FILL constraint 
were viewed as an instance of this RAP schema, the 
associated evaluation function would add the area* of 
the placed rooms (which are architecturally gauranteed 
to be inside the house and non-overlapping). 

Such specialized schemas match a conjunction of 
constraints (e.g., the most specialized RAP matches 
FILL A INS A NONOV). Initially, a global constraint is 
completely successfully matched against one of the less 
specialized RAP schemas. Each of the specializations 
of the RAP schema constitutes a potential reformu- 
lation opportunity. Such an opportunity is processed 
in a goal-directed fashion, in the sense that domain- 
specific instances of the additional constraints which 
must also be true to match the more specialized RAP 
schema are then sought among the conjuncts of P(o) 
(or proven to be antecedents for P(o)). 

Reformulating constraints for designing 
abstraction levels 

The HiT subcompiler (the subject of Sunil Mohan’s 
Ph.D. work [Moh91]) of KBSDE specializes in divid- 
ing the search algorithm architecture into two or more 
levels (if two, they are called the “base level” and the 
“abstract level”). Each of these levels has an asso- 
ciated search algorithm, configured from (constrained) 
generators, testers, and hillclimbing patchers (see, e.g., 
the earlier two-level example). 

A (generally global) constraint P(s) can serve as the 
basis for constructing an abstraction level in the follow- 
ing sense: An abstraction function mapping solutions 
8 into abstractions f(s) is constructed (e.g., f might ab- 
stract a “room” into a “room area”). An abstract gen- 
erator Generated : input, a:range(f)) can then be con- 
struct e i which ztz crates all elements a in '.ie range 
of f(s) ?(s) can abstracted into test P*>i, which 
is appi: able to aoacract candidate solutions. Thus 
one possible searcn algorithm for the ab stract level is: 

Generate^ : input, a : range(f)); 

Test(a | P'(a)) 


HiT currently is organized around two schemas rep- 
resenting constraint types whose very form makes it 
easy to construct an abstraction function: 

1. Functional constraints: P(F(s)). Based on such a 
constraint, the abstract level generates {z | z = 
F(s)} and the base level is then responsible for en- 
suring that P(refinement(z)) holds. 

2. Disjunctive con- 

straints: Vs, t[solution(s) A pariType(t , *) - Vp : 
T\part(p, s) Pl(p) V P2(p) V ... V Pn(p).j] The ab- 

stract level generator selects one of these disjuncts 
to be true by fiat (i.e., it posts the disjunct as a con- 
straint). The base level must then construct an s 
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that satisfies that disjunct. 

Compilability 

Reformulating a constraint into disjunctive 
form. Several general rules are used to carry out this 
reformulation (some of which are similar to those used 
to transform a predicate logic assertion into conjunc- 
tive normal form). These include: “Move negations in- 
ward”, “Reformulate the expression as a disjunction”, 
and “Remove variables that refer to non-solution ob- 
jects.” 

Using these transformations, a constraint such as 
NONOV: 

For all pairs of rooms R1 and R2, it is not that 
the case there exists a point p that is both inside 
room R1 and inside some other room R2. 

or: 

VR1, R2[Room{Rl) A Room(R2) A Rl ^ R2 

— (3p[Inside(p, Rl) A Inside(p, R2)]) 

is eventually re-expressed as: 

VR1, R2[Room(Rl) A Room(R2) A Rl £ R2 — 
[~L(R1,R2)V~ R(R1,R2) 

V - R(R1, R2)V - A(R1, R2)]] 

where the predicates are defined as follows: 

• L(R1,R2): The x coordinate of the right side of Rl 
is less than or equal to the x coordinate of the left 
side of R2. 

• B(R1,R2): The y coordinate of the top side of Rl is 
less than or equal to the y coordinate of the bottom 
side of R2. 

• R(R1,R2): The x coordinate of the left side of Rl 
is greater than or equal to the x coordinate of the 
right side of R2. 

• A(R1,R2): The y coordinate of the bottom side of 
Rl is greater than the y coordinate of the top side 
of R2. 

At this point, the constraint matches the “disjunc- 
tive constraint schema” and HiT can now proceed to 
construct an abstract level where, for every pair of 
rooms < Rl, R2 >, one of the four above relationships 
is generated as a constraint to be satisfied. 

Efficiency improvement 

Deriving composition laws for the disjunctive 
case. As is readily noticed, picking topological rela- 
tions at random between pairs of rooms is not likely 
to very rapidly converge on an abstract solution that 
is actually concretely realizable. 

Foitunateiy, because the predicates of disjuncts can 
be viewed as defining relations, we can sometimes ex- 
ploit known or provable properties of relations such 
as transitivity, reflexivity, or symmetry. Such proper- 
ties can be viewed more constructively as composition 
rules. Thus for the L(R1,R2) relation, the following 
two composition rules can be shown to hold: 


• Transitivity. If £(R1,R2) and L(R2 J R3), then 
£(R1, R3). 

• No reflexivity. -X(R1,R1). 

These composition laws can then be made opera- 
tional in several ways, including: incorporating them 
into the abstract generators using RICK; using them 
to dynamically prune the ranges of the abstract gener- 
ators; using them as abstract tests (supplementing the 
original test). 

Discussion and conclusions 
Summary 

In this paper, we have briefly described a number of re- 
formulation techniques for use during knowledge com- 
pilation, either to make constraints compilable in the 
first place, or to put them in a form that compiles into 
a more efficient search algorithm. The reformulation 
techniques described here are schema-specific; match- 
ing of a constraint to a given subcompiler’s schema can 
be aided by a reformulation technique, or a constraint 
that (already) matches a particular schema can be put 
in a form (possibly one that matches another schema) 
that will allow it to be more efficiently satisfied. 

Implementation status 

At this point, the reformulation techniques discussed 
for use in the RICK subcompiler have been imple- 
mented; the ones associated with the MENDER and 
HiT subcompilers are the subject of ongoing research. 

Related work 

Antecedent derivation. A schema-specific approach 
to schema-matching is usefully contrasted with a 
general-purpose approach, such as Smith’s antecedent 
derivation method [Smi82]. One difference (we believe) 
is that the “antecedent derivation” process for a given 
schema can be restricted to using a specified (small) 
set of inference rules associated with that schema. A 
second difference is that in some cases, our schema* 
specific reformulation technique is a “normalization” 
process that works in the forward direction (e.g., to 
put a constraint in a disjunctive form). 

DRAT. Like KBSDE, another schema-oriented ap- 
proach that is more specialized than Smith’s an- 
tecedent derivation method is Van Baaien’s DRAT sys- 
tem [BD88J. KBSDE’s target is an efficient generate- 
test-patch architecture; in contrast, DRAT’s target 
is an efficient (object-oriented) forward-chaining the- 
orem prover. Both systems take a classification- 
based approach to assigning specified constraints to 
schemas. However, KBSDE’s schemas correspond to 
generic search algorithm components such as gen- 
erator or patcher types, whereas DRAT’s schemas 
correspond to (efficient implementations for) generic 
forward-chaining rules. 
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Ia KBSDE, “incorporating a constraint” in a con- 
strained generator means that the constraint need no 
longer be represented explicitly in the problem solver; 
the generator is guaranteed to only produce accept- 
able solutions. Similarly, in DRAT, “capturing a con- 
straint” in a rule implementation also means that that 
constraint need not be explicitly mentioned in the 
problem solver. KBSDE’s ideal is to incorporate all 
constraints in a single (hierarchically organized) con- 
strained generator , which produces completely correct 
solutions in polynomial time. Since this ideal is sel- 
dom achieved (it would require finding a solution rep- 
resentation in which all constraints are localizable to 
solution parts), KBSDE has a set of fallback strate- 
gies: incorporate the “leftover” global constraints in a 
patcher, in new abstraction levels, or (least preferred) 
in a tester. 

D RAT’s analogue to our reformulation techniques 
for enabling compilability is called concept introduc- 
tion; by considering alternative formulations for one 
of the task’s concepts, DRAT can sometimes find a 
representation that allows more constraints to be cap- 
turable. A process called operationalization then tries 
to capture the “leftover”, uncaptured constraints by 
writing procedures and using these to further special- 
ize the already selected representations. 

Code optimization*. Our reformulations associated 
with efficiency improvement are similar in spirit to 
intermediate code optimization in standard compiler 
technology, in the sense that such optimisations are 
done: (a) at a level of abstraction higher than the tar- 
get level (in our case, reformulating constraints into 
other constraints); and (b) based on a thorough knowl- 
edge of how the compiler to the target level works. 

Research directions 

The set of reformulation techniques presented here is 
under development. Some of the areas still in need 
of further development are: techniques for reformu- 
lating constraints to match RAP schemas; techniques 
for matching the functional constraint schema; tech- 
niques for improving the efficient processing of func- 
tional constraints; and an elaboration of how to best 
exploit derived composition laws for newly constructed 
abstraction levels. 
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